-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Portability cleanup setsockopt() calls #1359
base: master
Are you sure you want to change the base?
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
src/WinSvc.cc
Outdated
@@ -965,7 +965,7 @@ static int Win32SockInit(void) | |||
} else { | |||
opt = opt | SO_SYNCHRONOUS_NONALERT; | |||
|
|||
if (::setsockopt(INVALID_SOCKET, SOL_SOCKET, SO_OPENTYPE, (char *) &opt, optlen)) { | |||
if (::setsockopt(INVALID_SOCKET, SOL_SOCKET, SO_OPENTYPE, reinterpret_cast<char *>(&opt), optlen)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are going to change so many callers, like the current PR iteration does, then we should polish/generalize and make our SetSocketOption() available to this and similar code, allowing us to move all the current ugly and poorly duplicated manual casts into one place.
The same approach will correctly handle the last/size arguments with less noise and fewer opportunities for bugs.
FWIW, I am happy to help with generalizing/polishing the existing SetSocketOption() code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As demonstrated in PR #1373 this is a deceptive request. Acceding will result in a fall down the slippery slope of ever increasing perfection requests. Throwing this PR further out of the intended scope of fixing a few MinGW compile errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As demonstrated in PR #1373 this is a deceptive request. Acceding will result in a fall down the slippery slope of ever increasing perfection requests. Throwing this PR further out of the intended scope of fixing a few MinGW compile errors.
I disagree with the above assessment and speculation. However, may not need to agree on this to make progress: If you refactor this PR so that it is just "fixing a few MinGW compile errors", without modifying so many setsockopt() calls (most of which are not specific and some are probably not even applicable to MinGW builds), then this change request will become stale/inapplicable and can be resolved on those grounds. I do not know whether (and am not implying that) such refactoring is possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT, this change request has not been addressed when PR branch was force-pushed from 02b82a1 to 213df95 and my re-review requested a few hours ago.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was addressed by authors decision not to implement your requested change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT, this change request has not been addressed when PR branch was force-pushed from 02b82a1 to 213df95 and my re-review requested a few hours ago.
It was addressed by authors decision not to implement your requested change.
Thank you for disclosing that decision; I was not aware of that decision when my re-review was requested.
This change request stands. Doing nothing does not address my blocking concern.
Waiting on PR #1373 |
No longer going to wait for PR #1373 which has already started devolving into requests for perfection. |
src/WinSvc.cc
Outdated
@@ -965,7 +965,7 @@ static int Win32SockInit(void) | |||
} else { | |||
opt = opt | SO_SYNCHRONOUS_NONALERT; | |||
|
|||
if (::setsockopt(INVALID_SOCKET, SOL_SOCKET, SO_OPENTYPE, (char *) &opt, optlen)) { | |||
if (::setsockopt(INVALID_SOCKET, SOL_SOCKET, SO_OPENTYPE, reinterpret_cast<char *>(&opt), optlen)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As demonstrated in PR #1373 this is a deceptive request. Acceding will result in a fall down the slippery slope of ever increasing perfection requests. Throwing this PR further out of the intended scope of fixing a few MinGW compile errors.
I disagree with the above assessment and speculation. However, may not need to agree on this to make progress: If you refactor this PR so that it is just "fixing a few MinGW compile errors", without modifying so many setsockopt() calls (most of which are not specific and some are probably not even applicable to MinGW builds), then this change request will become stale/inapplicable and can be resolved on those grounds. I do not know whether (and am not implying that) such refactoring is possible.
Ensure that parameter 4 is cast properly to char* which is known to be compatible with all known API declarations for this function. Ensure that parameter 5 is passed the size of object in parameter 4 whenever possible, instead of the theoretical type size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please address the earlier change request at #1359 (comment)
Per @rousskov 12 Oct 2024: "Please do not block PRs just because you do not see value in them (when other core developers do see value)." |
I am not blocking this PR because I do not see its value. I am currently blocking this PR because its value is overwhelmed by its harm, while addressing my concern (and reversing that relationship) does not require heroic efforts. |
error: cannot convert 'int*' to 'const char*'
Ensure that parameter 4 is cast properly to char* which is
known to be compatible with all known API declarations
for this function.
Ensure that parameter 5 is passed the size of object in
parameter 4 whenever possible, instead of the theoretical
type size.